OpenUDS: A demo-oriented crossplatform framework

Gongo/Green

Hi there,

this writing has been postponed for numerous reasons since february 2003. It was at about that time that I posted the first post on the subject on c.s.i.p.d.

After reading Hugi 26 (where this article was supposed to go), and later on Hugi 27, I grabbed the first notepad I could find and started typing away. (If not, this article wouldn't even have been in Hugi 42.)

The articles that sparked me to pick up the project Green was supposed to start in 1997-1998 were:

A Challenge for 2002 - Coplan / Immortal coil (Hugi #25)
  The coders part: innovate

In search of better softsynths - MrMessiah (Hugi #25)
  The need for a framework (ok, for softsynths in intros/demos)
  
Art of getting started - klocekSpiral (Hugi #25) 
  For the fact that some coders are lazy (or are not always 'in the mood
  for coding') or better put: need a lot of motivation

But the article I felt an urge to respond to was in Hugi #26. It was written by Lito, and it was called: "Coding the future". This article was so true that even though I started losing interest in the project again (for the reason that it somewhat got shot down in the first round of posts in c.s.i.p.d), I felt that itch again that needed scratching and regained interest.

I read this article that was supposed to be side by side with this one if only I had met the article deadline of Hugi #26, and got excited about the idea (of openUDS) again.

Since then a lot has been written, said and brainstormed on the concept of openUDS, so for those of you living under a rock, I'll try to recapture what the intention is and where it originated from.

It all started back in 1998.

A few events triggered in Green (the demogroup I was in) the conception of something we later called GDS (Green Demo System - the U stands for universal :-)):

- The release of the first linux demo (Hard Rox by skal) on Wired'98

- Jizz/TBL had been released earlier, featuring calculated textures and samples among other things

- The hell we went through at deadlines to get things synchronised, order of effects, what to render after what in case of combinations of effects etc (I'm sure some of you remember these things as well, if not: then bravo, you're one of the few who didn't ;-))

- Scripting engines were being used all of the sudden

- Early experimentation with the windows platform (for us, that was)

All of these led to the conception of creating a framework where effects could be used in any order you'd want, synchronised with a visual WYSIWYG tool that outputted a script and that was also portable to release a demo at the same time under DOS32, Win32 and linux/x86.

Sadly, thesis work, jobs, social life and fraternity responsibilities (I do not know how to translate this, but it is nothing like in 'American movies' here) as the presiding chairman put an end to this project in its early stages, and of Green in one way or another...

4 and a half years later, I regain a certain interest (nostalgia) in being an active scener (even though it is hard to focus after a hard days work in writing client/server soft ;-)).

However, I stumbled upon demopaja. The editor was in fact somewhat similar in concept to what we had in mind in those days, so I went on to congratulate memon for doing what we had failed to do.

There are however some fundamental differences in concept between openUDS and DemoPaja. A sample list (not all differences listed) is below:

openUDS                                  DemoPaja
- crosscompiler                          - MSVC only
- crossplatform                          - Win32 only
- wrapper for openGL and D3D             - openGL only
- rendertree for sequencing              - single pipeline without branching
- a framework in the first place         - editor/player + SDK
  and a few applications that work
  with this framework in the second
  place (among which an editor)

One thing led to another and the current status is this:

I am starting an open source project on sourceforge called openUDS, which will allow a completely configurable framework of plugins to operate with each other. Since I want to start as right as possible in design of the framework, I need feedback from coders that have experience in these areas:

- System programmers (audio/opengl/direct3D/timers/script engines) etc

- Plugin developers (what would you like to access from the audio system, for instance: Do you need access to callbacks? Why? Or to the audio data?)

The main features will include:

- Crosscompiler: Multiple compilers will be supported on each platform, as long as they create ABI compatible code on that platform), which will enable to have one executable - for instance in MSVC -, and the plugin dll's been compiled with Borland C++ or open Watcom for instance.

- Crossplatform: Planned platforms are initially Win32, GNU\Linux x86, but a port for MacOSX, DOS32 (for the oldskoolers ;-)) and the consoles could be an option as well

- has a testing suite for plugins

- lots and lots of documentation (not just the api, but users guide, programmers guides, ...)

- will feature at least one scripting language (for now, an xml document is proposed, but you could use your own if need be)

- will have a WYSIWYG tool for the script making

- will consist mainly of a few interfaces, classes and the standard set of system oriented and platform dependent (ported and used through a standard interface) plugins (timers, audio, video (opengl/direct3d), ...)

- "garbage collection"

- examples

- will have custom rtti for inspection and reflection on the plugins

- will have a java-like event system (with multiple inheritance through abstract interfaces (cfr Java2 class A extends B implements C,D,E)

- will have some old-skool enabling (virtual acces to a framebuffer) possibilities (looks into the past) as well as support for vector/fragment/ pixel/object shaders (looks into the future) in a platform and driver independent way (cfr XEngine @ sourceforge).

I admit this is a very ambitious project, and grown exponentially from where Green originally got this idea (as did others, take a look around at demoGL, smode, the nebula device, ... for instance).

As a few last reasons I would want everybody thinking about the 'my pc is not able to run this or that demo because it requires version x of software library y or extension z, which I do not have'. By providing wrappers to openGL/ DirectX for instance that have the same interface, a user that has an up to date directx driver for his system, but a discontinued openGL driver can still view an openGL(-preferring) demo if at startup he/she sets up the system to use the directx plugin or -as a last resort- try to use the software rendering system of the openGL 1.4 compatible Mesa3D library. A custom engine could still be wrapped up inside an object that binds to the proprietary code.

So, when everybody uses the same system (which is open source!), a lot more improvements can be made regarding bugfixing etc, which will lead to stability across platforms etc and in the end might lead to a common platform for demos or somewhat of a DemOS (remember those hypes? :-)).

On a sidenote, I have been approached for 2 other applications that possibly might be based on this framework as well (next to the editor). One is a VJ-ing software and one is an alternative for the big-screen-program most parties seem to be using. I am sure in the future other applications will follow suit, as is usually the case for versatile open source projects :-).

The project is also looking for talented scene coders to contribute to the project. The profile should be something along the lines of:

- have scene experience

- knows C++ well enough to get around with rtti concepts, templates (a notion of it is ok already), abstract classes, overriding, ... OOP in general

- has a little notion of the Java2 (just a plus, not a prerequisite) language and architectural concepts.

- has done some 'system' programming on his/her platform (script engine, virtual file systems, audio, video programming (directX, openGL, SDL, VESA, ...)

- has not a problem that the source will be released (duh, since it is an open source project! ;-))

They could always reach me at gongo at vt4 dot net for applications, feedback, or on the sourceforge pages of the openUDS project through the trackers:

http://www.sourceforge.net/projects/openuds

If you want to be part of this effort, then join us!

Not only coders are needed, also gfx artists (for the gui ;-)), documenters, early adopters, testers, ...

As you can see that writing this (completely redesigned) project in spare time is going to take ages if we alone will do it, as the concept is VERY ambitious and reaching those goals is going to be hard, especially if they are to be met reasonably fast (let's say within 1 to 2 years from now, although I am not pinpointing a date, when we have the time and do it alone). If you have any ideas or comments, you can also contact me at the aforementioned address.

In closing, I would like to add that I am in the progress of combining all that is written and said over the last few months into a public document that will be downloadable from the project pages of openUDS by the time this article is released as part of the new Hugi diskmag. Maybe there will be an early source distro by then of some of the basic parts of the system. Mind you, that the first distribution will not be a complete system, but just something that you can toy with and comment upon.

grtz,
Dimitri Smits

aka Gongo / Green ^ openUDS team